Tunnel broker management

ABSTRACT

A tunnel broker ( 4 ) configures a first node ( 2 ), which supports first and second communications protocols, e.g. IPv4 and IPv6, to communicate with a second node which supports IPv6, over an IPv4 network. The tunnel broker ( 4 ) assigns a unique IPv6 address ( 10 ) to the node, generated using a combination of the IPv4 address ( 11 ) of the node and a counter value ( 13 ). The counter is incremented for each user sharing an IPv4 address ( 11 ), so that each user sharing an IPv4 address ( 11 ) is allocated a unique IPv6 address ( 10 ). The tunnel broker service is restricted to users who have created an account. An account password is sent to the user&#39;s e-mail address, ensuring that a person giving a false address cannot gain access. A user cannot create further accounts using the same e-mail address. The number of tunnels that can be configured using each account is limited. These measures act to prevent an individual configuring a large numbers of tunnels ( 1 ) in a denial of service attack.

The invention relates to facilitating communication between hosts via anetwork such as the Internet. Particularly, but not exclusively, theinvention relates to a method of tunnel broker management and a tunnelbroker for allowing nodes that support one protocol, to communicate viaa network that supports a different protocol.

Communication over a network such as the Internet is governed by a setof rules, or protocols, which allow information to be divided intopackets, sent through the network via one or more routes and reassembledat their destination. At the present time, the most widely used protocolis Internet Protocol version 4 (IPv4). An IPv4 packet header includesthe address of the device sending the information and its destination,where each address is expressed using 32 bits in the form of four 8-bitnumbers, or octets, e.g. 213.38.220.226. However, this formataccommodates only a limited number of addresses. Use of the Internet hasincreased sharply in recent years and it is expected that growth willcontinue, due to an increase in the number of users and the greaterrange of devices, such as personal computers and mobile phones, whichmake use of the Internet. This is likely to lead to a shortage of IPv4addresses.

A newer version of the above protocol, Internet Protocol version 6(IPv6), is described in Request for Comments RFC 2460, The InternetSociety, December 1998. IPv6 overcomes this problem by providing alarger address space in its headers. An IPv6 address uses 128 bits inthe form of 16 octets, greatly increasing the number of availableaddresses. However, it is not feasible for all the devices and networksconnected to the Internet to migrate to IPv6 at once. The changeoverbetween the two protocols is a gradual ongoing process as new devicesand applications supporting the new protocol become available andindividual hosts and networks begin to use IPv6. There will be a longperiod of transition during which both protocols will coexist. This willrequire inter-operability measures to meet the demands of IPv6 usersneeding to send data over networks configured using IPv4.

One method of addressing this problem is “tunnelling”, which allowsusers with an IPv4 connection to gain access to an IPv6 network. Theuser has a dual-stack node, i.e., a host or router that supports bothprotocols, referred to hereafter as an end user node. A tunnel iscreated between the end user node and the IPv6 network by encapsulatingIPv6 packets within an IPv4 datagram, so that they can be sent to theirdestination over an IPv4 network. Until recently, the small number oftunnels in use were manually configured and maintained, resulting in aheavy management load on network administrators. This will increasefurther as greater numbers migrate to IPv6.

This problem is being addressed by the provision of dedicated servers,which automates the management for creation and maintenance of tunnels,known as tunnel brokers. A tunnel broker is described in the Request forComments RFC 3053, The Internet Society, January 2001, where the tunnelbroker creates, modifies and deletes tunnels in response to requestsfrom a user. The tunnel broker configures the remote end of the tunneland sends information for configuring the user's tunnel end point to theuser's node.

The tunnel brokers presently in use tend to cater for small numbers ofusers. However, particular problems may arise when accommodating dynamicIP users who do not retain the same IPv4 address each time they connectto the network.

According to one aspect of the invention, there is provided a method ofconfiguring a first node, which supports first and second communicationsprotocols, to communicate with a second node, which supports the secondprotocol, over a communications network which operates according to thefirst protocol, wherein the first node is associated with a firstaddress for use with communications which conform to the first protocol,the method including the steps of receiving a request for allocation ofa second address for use by the first node for communications whichconform to the second protocol, in response to the request, generating avalue, combining the value with the information relating to a user ofthe first node to generate a unique second address and allocating thesecond address to the first node.

For example, there may be situations where an IPv4 address may beassociated with more than one user, for example where a network isaccessed via an Internet service provider. Many Internet serviceproviders assign an IPv4 address to a user from a pool of addresses eachtime they connect to the network, and so, over a period of time, aparticular IPv4 address might be assigned to a number of differentusers. As the configuration of any tunnels necessarily includes thetunnel end point address, the allocation of a single IPv6 tunnel endpoint address to each given IPv4 address would result in tunnels beingshared between users. This is avoided by giving each user a unique IPv6tunnel end point address, in a method that is suitable for both dynamicand static IP users.

In a preferred embodiment of the present invention, requests forallocation of a second address are accepted only from those users whohave created an account, where the creation of said account requires thecompletion of a registration process in which the user supplies acurrent address, and wherein the creation of further accounts by a usersupplying the same address is prevented.

It is possible that users may seek to misuse or abuse an automatedsystem by creating an excessive number of tunnels. As tunnel servers(the second node) have finite resources, this activity may eventuallybring about a denial of service. A person intending to initiate adenial-of-service attack would have to create multiple accounts. Toprevent this, the accounts created by the user are associated with theire-mail address and the tunnel broker prohibits the creation of multipleaccounts using a single e-mail address. It is also preferable for themethod to include sending an account password to the e-mail addressprovided by the user, thereby preventing a person registering a falsee-mail address from gaining access to the tunnel broker. In a furtherpreferred embodiment of the present invention, the method furthercomprises:

-   -   evaluating the performance of a plurality of available nodes;        and    -   using the results of the evaluation to select a second node from        the plurality of available nodes.

According to the invention, there is also provided a tunnel broker forconfiguring a first node, which supports first and second communicationsprotocols, to communicate with a second node, which supports the secondprotocol, over a communications network which operates according to thefirst protocol, wherein the first node is associated with a firstaddress for use with communications which conform to the first protocol,comprising means for receiving a request for the allocation of a secondaddress for use by the first node for communications which conform tothe second protocol, means for receiving information relating to a userof the first node, means for generating a value in response to therequest, means for combining the value with the information relating tothe user to generate a unique second address and means for assigning thesecond address to the first node.

Preferably, an interface is provided so that the user may submit arequest for the tunnel broker to configure a tunnel, and for the user tomonitor their tunnel, for example via a web page. Allowing the user toconfigure a tunnel and then to monitor it reduces the need for manualintervention by the network administrator.

In a preferred embodiment, the tunnel broker also comprises means forsynchronising the configuration of a second node with the configurationstored by the tunnel broker, the synchronising means being arranged:

-   -   to compare the configurations stored on the tunnel broker with        configuration information stored on the second node;    -   to determine which configurations are stored on only one of the        tunnel broker and second node; and    -   where a configuration is stored on the tunnel broker and not the        second node, to copy the configuration stored on the tunnel        broker to the second node.

According to a second aspect of the invention, an address structure foruse in a system that facilitates communications between a first node,which supports first and second communications protocols, with a secondnode which supports the second protocol, over a communications networkwhich operates according to the first protocol, wherein the first nodeis associated with a first address for use with communications whichconform to the first protocol, comprises a first portion correspondingto the first address and a second portion corresponding to a value,wherein the combination of the first and second portions is unique.

Embodiments of the invention will now be described by way of examplewith reference to the accompanying drawings, in which:

FIG. 1 shows the functional elements which make up the tunnel brokermodel set out in RFC 3053,

FIG. 2 is a schematic diagram illustrating a tunnel broker systemaccording to the invention,

FIG. 3 is a flowchart showing how a user creates an account on thetunnel broker,

FIG. 4 is a flowchart showing how a user creates a tunnel via the tunnelbroker,

FIG. 5 depicts an IPv6 tunnel end point address assigned to a node,

FIG. 6 is a flowchart showing the association of an expiry period with atunnel created by the user,

FIG. 7 is a flowchart depicting the synchronisation of the tunnel brokerand tunnel server.

FIG. 1 shows the tunnel broker model set out in RFC 3053 referred toabove. A tunnel 1 is created between two tunnel end points, an end usernode 2 and one of a number of tunnel servers 3 a-c. The end user nodecomprises a dual-stack host or router, which is capable of handling dataencoded according to either of the IPv4 and IPv6 protocols. The tunnelis configured by a tunnel broker 4, which comprises an applicationprogram running on a dedicated server machine. The tunnel server 3 a-ccomprises a dual stack router connected, for example, to the Internet.

The model includes a Domain Name Server (DNS) 5. Although IP addressesare expressed as a series of numbers, most addresses also have domainnames associated with them, where the address is specified by a seriesof words, for example, ‘www.bt.com’, which users tend to prefer. A DNS 5maintains a look-up table of domain names and IP addresses. When a userenters a domain name, a request is sent to one or more domain nameservers and the corresponding IP address is retrieved, a processreferred to as forward look-up. A further process known asreverse-lookup is also used to map IP addresses to names and a number ofapplications use this procedure to verify the origin of a user beforeallowing access to their services.

FIG. 2 depicts a system for connecting an end user node 6 having an IPv4Internet connection, to an IPv6 network 7 via an IPv4 network 8, forexample the Internet, under the control of a tunnel broker 4. The enduser node 6 includes a dual stack node 2, which is implemented as partof the operating system, as currently supported by most major operatingsystems. The system allows the end user node 6 to communicate with anIPv6 Internet Service Provider (ISP) 9, which includes a tunnel server 3a, via the IPv4 network 8 over the tunnel 1. Data packets created at theend user node 6 intended for the IPv6 network 7 and including addressinformation in the header, are encapsulated in an IPv4 datagram. Thedata is transmitted via the IPv4 configured network 8 to the ISP 9,where the data is un-encapsulated by the tunnel server 3 a and thentransmitted onto the IPv6 network 7.

A user of the end user node 6 can request the creation of a tunnel 1 bythe tunnel broker 4 via a web-based user interface. However, they mustfirst register with the tunnel broker service. Referring to FIG. 3,beginning at step s0, a web page is displayed to the user (step s1) whoselects an option to create an account (step s2). The user then submitsregistration details (step s3), including their e-mail address.

An account is then created on the tunnel broker 4, which is associatedwith the user's e-mail address (step s4). The tunnel broker randomlygenerates a password for use by the user for access to their account onthe tunnel broker (step s5). The password is sent to the e-mail addressthat they have provided (step s6). This prevents a person who registersunder a false e-mail address gaining access to the tunnel broker.

The tunnel broker also assigns a limit to the number of tunnels that canbe created in each account (step s7). The tunnel broker is configured toprevent the creation of multiple accounts using a single e-mail address,so that the combination of these measures prevents end users fromrepeatedly creating tunnels. The creation of a large number of tunnels,malicious or otherwise, would occupy valuable resources on the tunnelserver and could result in a denial of service.

Once an account has been created, the user activates their account bylogging onto the service using the password (step s8). Once theiraccount is activated, they may change the password to one of their ownchoice (step s9).

Finally, an expiry date is associated with the account so that anaccount is deleted if the user does not log in for an extended period oftime, e.g. three months. A timer is set when the account is firstactivated (step s10) and proceeds to count down until a threshold isreached. The timer is reset whenever the user logs in to their account.

The account creation process is then complete (step s11). The user cannow create and configure tunnels, as shown in FIG. 4. Starting at steps12, the user visits the tunnel broker web page (step s13) and logs inusing his password (step s14). As mentioned above, the account expirytimer is reset when the user logs in (step s15). The user then selectsan option to create a tunnel (step s16). The number of tunnels that canbe created by a user is limited, and the tunnel broker checks whetherthe quota associated with the user's account has been filled (step s17).If it has, the user's request is rejected (step s18).

If the user's request is accepted, the tunnel broker 4 requests the IPv4address of the end user node 6 (step s19). The tunnel broker 4 maintainsa database of IPv4 addresses submitted by registered users of theservice. The dual stack node IPv4 address is checked against theaddresses stored in the database, to determine whether it matches onepreviously submitted by another registered user (step s20). The tunnelbroker 4 maintains counters associated with each registered IPv4address. The value of a particular counter is incremented each time adifferent user with the same IPv4 address requests a tunnel (step s21),i.e., if the IPv4 address is already listed in the database.Alternatively, the counter value could be decremented for each user withthe same IPv4 address. Otherwise, the counter is set to an initialvalue, for example, zero (step s22).

The combination of the counter value and the IPv4 address is unique foreach user. The tunnel broker uses this combination to form part of aunique IPv6 tunnel end point address, which it assigns to the end usernode 6 (step s23). Referring to FIG. 5, the IPv6 address 10 comprises128 bits. The last 32 bits 11 correspond to the host's IPv4 address. An8-bit tunnel server number 12 indicates which server the tunnel isconfigured on, for use where a single tunnel broker 4 is managing morethan one tunnel server 3 a-c. The tunnel server number 12 is, forexample, a number between 0 and 255. The IPv6 tunnel end point address10 includes the counter value, in the form of a 24-bit number 13. A24-bit counter value allows 2²⁴ users to share a single IPv4 addresswhile ensuring that the last 64 bits of the IPv6 address assigned toeach user is unique.

Although this particular embodiment uses an IPv4 address and a counterto identify a particular user, any combination of information uniquelyidentifying an individual users could be used. For example, personalinformation, such as a date of birth, relating to a user could beencoded and used in place of the IPv4 address. Furthermore, the countercould be replaced with another number such as their room number, theirtelephone extension number, a randomly generated number or, where thesame value has not been used in place of the IPv4 address, their date ofbirth. However, the use of a counter ensures that each address assignedby the tunnel broker is different, so it is not necessary to checkwhether the complete address matches one assigned to another node.Furthermore, when combined with an IPv4 address, a counter value 13results in the tunnel end point addresses associated with a given IPv4address being kept together in consecutive address blocks, minimisingrouting complexity.

As mentioned above, a tunnel broker 4 can manage multiple tunnel servers3 a-c. For example, a company using the tunnel broker service may have anumber of sites that are separated geographically, so it may beconvenient to provide a local tunnel server for each location, or anincreased capacity may be required. Referring again to FIG. 4, thetunnel broker 4 performs tests to determine which of the tunnel servers3 a-c the new tunnel 1 should be configured on (step s24). Severalfactors may be taken into consideration. The tunnel broker 4 submitsinstructions to each tunnel server 3 a-c to execute a command. The host6 measures the performance of each of the tunnel servers 3 a-c andreturn the results to the tunnel broker 4 for determining which serveris most suitable. The performance can be evaluated in terms of delay,e.g. using ping, throughput or number of hops taken, for example, usingtraceroute. The decision can also be based on a comparison of the loadson each server, and by taking into account the interests of the user asdefined in their service level agreement.

Having made a selection, the tunnel broker 4 configures one end point ofthe tunnel on the selected tunnel server 3 a (step s25) beforeinitialising and activating an associated timer (step 26), the functionof which will be explained in detail below. The tunnel broker 4 thensends an email to the user containing the end user node configurationscript, which configures the tunnel end point at the dual stack node 2(step s27). Alternatively, the tunnel broker 4 may send a request to theuser, asking them to download the configuration script via the userinterface web page. Running the script sets up a routing table to tunnelall IPv6 traffic from the end user node 6 to the tunnel server 3 a. Thetunnel is considered activated when both end points have beenconfigured.

Once the tunnel has been activated, the user may also associate a namewith the tunnel end point, by selecting an option on the user interfaceweb page (step s28). The tunnel broker then sends a request to updatethe Domain Name Server (DNS) 5 (step s29). The tunnel creation processis then complete (step s30).

An administration interface is also provided, in the form of a web page,for use by a network administrator with responsibility for the tunnelbroker service. By using the administration interface, the administratorcan monitor the creation of accounts and tunnels, view lists andstatistics of tunnels and accounts, maintain the service and respond touser requests, e.g., by adjusting the tunnel creation limit for a useraccount. The administrator may also select options presented on theadministration interface to prohibit access to the service from certainIPv4 addresses or disable tunnels and accounts.

Where a tunnel broker 4 manages multiple tunnel servers 3 a-c, asdescribed above, a share of the available address space must beallocated to each of the tunnel servers 3 a-c. It is preferable for eachtunnel server to be assigned a single large address block, rather than anumber of smaller blocks, to minimise routing complexity.

In the following example, the notation /x will be used to denote thenumber of bits that have been predefined. For example, a /40 addressblock indicates addresses where 40 bits have been predefined but theremaining bits are available for use, e.g. for allocating differentaddresses to hosts. The notation y /x denotes y address blocks where xbits have been predefined, so that the term 4 /40 address blocks refersto 4 address blocks, each of which have 40 predefined bits.

A tunnel broker 4 is assigned single or multiple /40 address blocks,i.e. a number of addresses that may be allocated to users. Theseaddresses will be allocated to users in the form of /128 tunnel endpoint addresses, /64 subnet address blocks and /48 network addressblocks. Each tunnel server 3 a-3 c may be assigned one of these /40address blocks. Therefore, a single tunnel server 3 a in this examplecould then allocate up to 65535 /64 address blocks and 255 /48 addressblocks, although the relative proportions of /64 and /48 address blocksmay differ between the tunnel servers 3 a-c.

The tunnel broker 4 monitors the number of /48 address blocks allocatedfor the creation of smaller /64 address blocks on a per tunnel basis. Ifa need for further /64 address blocks arises, the tunnel broker 4selects a /48 address block for use in assigning /64 addresses. If nofurther address blocks are available on a tunnel server 3 a, the tunnelbroker 4 may assign it another /40 address block.

A user may also be allocated one or more /64 or /48 address blocks,selected from a pool of available addresses. The /64 or /48 addressblocks are not bound to the configured tunnels as the configuration ofthe address block allocation on the end user node is independent of the/128 tunnel endpoint configuration.

The tunnel broker 4 allows end users to migrate their old /64 and /48address block allocations and bind them to new /128 endpoint addresses.For example, there may be situations in which a user changes their IPv4address. The tunnel broker 4 is flexible enough to allow any /64 or /48address blocks assigned to that user to migrate to the new IPv4 addressand be bound to new /128 end point addresses 10.

The user may submit a request to the tunnel broker 4 for the assignmentof a /48 address block. However, it is not desirable for such anallocation to be made automatically. Instead of meeting this requestimmediately, the tunnel broker 4 appends it to an “AwaitingAuthorisation” queue and notifies the network administrator withresponsibility for the tunnel broker 4, e.g., by e-mail or SMS. Thequeue is presented to the network administrator via the administrationinterface, along with any necessary end-user information. The networkadministrator may elect to contact the end-user, or carry out otherchecks, before permitting the assignment.

The user may request the right to manage the reverse lookup zone thatcorresponds to their allocated address space by selecting an option onthe user interface web page. The user can then submit the names of oneor two Domain Name Servers that will manage the reverse zone. The namesof the Domain Name Servers submitted by the user are sent to the DomainName Server 5.

There is a risk that a significant proportion of the memory may beoccupied by tunnel configurations and accounts that, for one reason oranother, are no longer in use. For example, a user may have registeredfor the purpose of testing the service and may not wish to continueusing it. It is desirable to minimise the number of obsolete tunnels andaccounts configured on the tunnel broker and tunnel servers, as theseoccupy the resources in terms of memory and available addresses. Alimited lifespan is defined for each tunnel, e.g. 20 days. As mentionedin relation to FIG. 4 above, a timer is set to this value and activatedto count down accordingly (step s26).

Referring to FIG. 6, after the timer has been set (step s26), the tunnelbroker 4 determines whether the user has reset the tunnel (step s31).The reset facility can be provided via the user interface web page. Ifthe user has reset the tunnel, the timer is reset to its initial valueand the countdown is restarted (step s26).

If the user has not reset the tunnel, the timer value is decreased byone for each day that has elapsed (step s32). When the countdown reachesa threshold value, for example 3 days, but has not expired (steps s33,s34), an e-mail is sent to the user (step s35) inviting them to resetthe tunnel activation and warning them that failure to do so within theremaining time will result in the tunnel being deleted. If the user doesnot do this, reminder e-mails will be sent on a daily basis until thetimer reaches zero. If the timer reaches zero (step s34), the tunnel isdeleted (step s36) and the process ends (step s37).

A similar procedure can be used for the account expiry timer in FIG. 3(step s10), where the user is sent daily warnings by e-mail when thecountdown drops below a predetermined threshold and unused accountsdeleted when the countdown reaches zero. These measures ensure that thetunnel server maintains only those tunnels and accounts that are in use.The user's /128 tunnel end point addresses and any allocated /64 or /48address blocks are maintained for a short period, e.g., 1 month, afterthe deletion of their account, for use should the user wish toreactivate their account. After this period, the addresses are returnedto the pool of available address blocks.

The administrator can disable either or both of the timer functions fora selected tunnel and/or account via the administration interface.

Another situation that may produce obsolete tunnels for the duration ofthe tunnel countdown arises where a user changes their IPv4 address. Asthe IPv6 tunnel end point address 10 contains the user's IPv4 hostaddress, a dynamic IP user, or a particular user who has changed theirIPv4 address, is assigned a different IPv6 tunnel end point address bythe broker 4 each time a change occurs.

The tunnel broker 4 supports a facility that allows the user to requestthat the configuration of one or more pre-existing tunnels is copied andmodified for use with their new IPv6 tunnel end point address 10. Thetunnel broker 4 creates a new tunnel with the same specification as theprevious tunnel, but associated with the user's new IPv6 tunnel endpoint address 10, and deletes the original one. The tunnel configurationalso includes a flag to indicate whether the user has a dynamic orstatic IPv4 address, so that the configuration of a new tunnel anddeletion of a previous tunnel can be performed automatically when adynamic IP user logs into their account.

The tunnel broker and tunnel server resources may also be occupied byobsolete accounts and tunnels where a user has changed their e-mailaddress. This may arise, for example, where a user changes Internetservice provider and is assigned a new e-mail address. The user'saccount and, therefore, the tunnels they have configured, are associatedwith their previous e-mail address. The user is allowed to modify thee-mail address associated with their account and continue using thetunnels that they have created.

A user wishing to change the e-mail address associated with theiraccount logs in and submits their new e-mail address via the userinterface web page. The tunnel broker will then generate a randompassword which is sent to the new e-mail address. The user must then usethis password to gain access to their account. If such a measure is notpresent, a user could change their registered e-mail address to a falseone and then create a new account using their genuine e-mail address.This would circumvent the measures for preventing denial-of-serviceattacks.

The tunnel server configurations are backed up on a non-volatile mediumwhenever a new tunnel is created so that, in the event of a failure, thetunnels could be restored. Restoration may be necessary, for example,following corruption of the tunnel server memory, or followingreplacement of the tunnel server 3 a. However, the tunnel server 3 a maynot allow the configuration to be saved and restored in this way, so anautomatic synchronisation method is provided on the tunnel broker 4.

The method of synchronisation is described with reference to theflowchart of FIG. 7, beginning at step s38. Firstly, the tunnel broker 4checks which tunnels it has configured (step s39) and then ascertainswhich tunnels are maintained on the tunnel server (step s40). The tunnelbroker then determines if the two sets of tunnel data correspond witheach other (step s41) and identifies any tunnels that exist on thetunnel broker but not on the tunnel server and vice versa (step s42).The network administrator can then select one or more tunnels that aremissing from either the broker or the server for synchronisation.Alternatively, the network administrator can select all tunnels, inwhich case all the tunnels configured between the broker and server willbe automatically synchronised. The tunnel broker 4 determines whichtunnels have been selected by the administrator (step s43) andsynchronises them by copying the relevant tunnel data from the broker tothe server, or vice versa (step s44), thereby completing the process(step s45).

However, it is possible that tunnels may be configured on the tunnelserver 3 a that were not created or are not maintained by the tunnelbroker 4. The tunnel broker 4 can compile a list of tunnels falling intothis category, which can be inspected via the administration interface.An administrator may then select tunnels from this list for deletion or,alternatively, associate the tunnels with an account on the tunnelbroker 4.

The specification of each of the tunnels managed by the broker is alsosaved onto a non-volatile storage medium periodically to maintain anup-to-date router configuration.

The user can access statistical information for monitoring theperformance of their tunnel. The results are presented to the user in asuitable format, e.g., as raw data or arranged into tables and graphsthat may be viewed on a web page. The tunnel broker 4 can be configuredto collect data and perform analyses, such as trending, automatically atregular intervals for presentation to the user.

The tunnel broker 4 also compiles administration statistics, such as thenumber of tunnels created in a given time period, new registrations,number of re-activated tunnels, numbers of expired tunnels so that theseare readily available to the network administrator. The administrationinterface includes menu options allowing the administrator to requestthe statistics for individual accounts and tunnels, such most recentaccess or number of packets sent and to view the trends on an hourly,daily or monthly basis. The data may indicate misuse of the system,e.g., by a user sending a high volume of traffic through a tunnel in anattempt to bring about a denial of service. The administrator can usethe statistics to identify the user and suspend access to their tunneland/or account.

The statistical data can be stored at regular intervals to allowanalysis of long term trends. For example, if the data reveals a sharpdrop in the number of newly created tunnels, the service provider mayconclude that a competing provider has created a better, or cheaperservice, or that consumer awareness of his own service is low, providingindications on how the service or its marketing could be improved.

1. A method of configuring a first node, which supports first and secondcommunications protocols, to communicate with a second node, whichsupports the second protocol, over a communications network whichoperates according to the first protocol, wherein the first node isassociated with a first address for use with communications whichconform to the first protocol, the method including the steps of:receiving a request for allocation of a second address for use by thefirst node for communications which conform to the second protocol; inresponse to the request, generating a value ; combining the value withinformation relating to a user of the first node to generate a uniquesecond address; and allocating the second address to the first node. 2.A method according to claim 1, wherein the information relating to theuser is the first address.
 3. A method according to claim 1, wherein thestep of generating a value comprises incrementing or decrementing avalue generated in response to a previous request.
 4. A method accordingto claim 1, wherein the step of generating a value comprises encoding anitem of personal information relating to the user.
 5. A method accordingto claim 1, wherein the step of generating a value comprises generatinga random number.
 6. A method according to claim 1, wherein each node hasa plurality of users and an associated first protocol address for usewith communications that conform to the first protocol and the value isunique for each user sharing the same first protocol address.
 7. Amethod according to claim 1, wherein the step of combining the value andthe information relating to the user to generate the unique addressfurther comprises including a number identifying the second node in theunique address.
 8. A computer program which, when executed by aprocessor, performs the method of claim
 1. 9. A tunnel broker forconfiguring a first node, which supports first and second communicationsprotocols, to communicate with a second node which supports the secondprotocol, over a communications network which operates according to thefirst protocol, wherein the first node is associated with a firstaddress for use with communications which conform to the first protocol,comprising: means for receiving a request for allocation of a secondaddress for use by the first node for communications which conform tothe second protocol ; means for receiving information relating to a userof the first node; means for generating a value in response to therequest; means for combining the value with the information relating tothe user to generate a unique second address; and means for assigningthe second address to the first node.
 10. A tunnel broker according toclaim 9, wherein the information relating to the user comprises thefirst address.
 11. A tunnel broker according to claim 9, wherein thegenerating means is a counter, which increments or decrements a valuegenerated in response to a previous request.
 12. A tunnel brokeraccording to claim 9, wherein the generating means comprises means forencoding an item of personal information relating to the user.
 13. Atunnel broker according to claim 9, wherein the generating meanscomprises means for generating a random number.
 14. A tunnel brokeraccording to claim 9, wherein the value is unique for each one of aplurality of users of the first node, where the first node has a firstprotocol address for use with communications conforming to the firstprotocol and the users share the same first protocol address.
 15. Atunnel broker according to claim 8, wherein the means for combining thevalue with the information relating to the user also includes a numberidentifying the second node in the unique second protocol address.
 16. Atunnel broker according to claim 9 wherein the first protocol isInternet Protocol version
 4. 17. A tunnel broker according to claim 9,wherein the second protocol is Interne Protocol version
 6. 18. A tunnelbroker according to claim 17, further comprising means for configuringthe second node to communicate with the first node.
 19. A tunnel brokeraccording to claim 18, further comprising means for storing theconfiguration of the second node and means for synchronising theconfiguration of the second node with the stored configuration.
 20. Atunnel broker according to claim 9, further comprising means forincluding in the configurations of the second node an attribute thatindicates whether a first protocol address associated with the firstnode for use with communications conforming to the first protocol isstatic or assigned dynamically.
 21. A tunnel broker according to claim20, further comprising means for automatically reconfiguring the firstand second nodes in response to a change in the first protocol address,where the attribute indicates that the first protocol address isdynamically assigned to the first node.
 22. An address structure for usein a system that facilitates communications between a first node, whichsupports first and second communications protocols, with a second node,which supports the second protocol, over a communications network whichoperates according to the first protocol, wherein the first node isassociated with a first address for use with communications whichconform to the first protocol, comprising a first portion correspondingto the first address and a second portion corresponding to a value,wherein the combination of the first and second portions is unique. 23.An address structure according to claim 22, wherein the value isprovided by a counter.
 24. An address structure according to claim 22,further comprising a number identifying the second node.
 25. A methodaccording to claim 1, wherein requests for allocation of a secondaddress are accepted only from those users who have created an account,where the creation of said account requires the completion of aregistration process in which the user supplies a current address, andwherein the creation of further accounts by a user supplying the sameaddress is prevented.
 26. A method according to claim 25, furthercomprising associating said second address allocated in response to arequest with the respective user's account and limiting the number ofsaid second addresses that can be associated with each account.
 27. Amethod according to claim 25, further comprising generating a passwordand sending the password to the current address supplied by the user.28. A method according to claim 1, further comprising: evaluating theperformance of a plurality of available nodes; and using the results ofthe evaluation to select a second node from the plurality of availablenodes.
 29. A method according to claim 28 further comprising:configuring the second node to communicate with the first node; andproviding a command script which, when run on the first node, configuresthe first node to communicate with the selected node.
 30. A methodaccording to claim 28, wherein the performance is evaluated using one ormore of the following parameters: hop count, load, throughput or delay.31. A method according to claim 28, wherein the selection of the secondnode is also based on a service level agreement.
 32. A tunnel brokeraccording to claim 19, wherein said means for synchronising theconfiguration of a second node with the stored configuration arearranged: to compare the configurations stored on the tunnel broker withconfiguration information stored on the second node; to determine whichconfigurations are stored on only one of the tunnel broker and secondnode; and where a configuration is stored on the tunnel broker and notthe second node, to copy the configuration stored on the tunnel brokerto the second node.
 33. A method according to claim 32, wherein, where aconfiguration is stored on the second node and not the tunnel broker,said means for synchronising are arranged to copy the configurationstored on the second node to the tunnel broker.